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Description 

PRESENCE REGISTRATION AND ROUTING NODE 

Related Application Information 
This application claims the benefit of United States Provisional Patent 
Application Number 60/191,278. filed March 22, 2000. and is a continuation 
of United States Patent Application No. 09/627,523, filed June 28. 2000. 
(pending) the disclosures of each of which are incorporated herein by 
reference in their entirety. 
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Technical Field 

The present invention relates to presence database services, and 
more particularly to the routing and processing of presence service related 
signaling messages in a communications network. 



Background Art 

Instant messaging (IM). as it is currently known within the 
communications industry, is an Internet technology that allows subscribers to 
send and receive text messages, voice messages and other data in near 
20 real-time. While IM started as a way to chat with friends, the technology has 
become an essential tool for many businesses, as it offers the convenience 
of e-mail and the immediacy of a phone call, as well as file transfers and 

voice messaging. 

Instant messaging is possible because the people sending and 

25 receiving messages remain constantly connected to their IM service. 
Recipients get messages as fast as the data can travel across the Internet. 
Conventional e-mail, on the other hand, is less immediate. E-mail 
technology sends messages to a server that stores the items until they are 
downloaded by the recipient's e-mail software. Many industry experts argue 

30 that it is the "instant" or near real-time communication characteristic that has 
made and will continue to make IM a mode of communication in the future. 
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At present, when a subscriber logs in to an IM service, the 
subscriber's software no*, a presence server or similar client based 
presence system that the subscriber is available to receive messages. Such 
a scenario is generally illustrated in Figure 1 . Once the subscriber is logged 
5 in or "registered." the subscriber can choose to send a message to another 
online user. From a network communication perspective, such a 
communication is accomplished via the sending of data packets contain.ng 
address and user-type information to the intended recipient. Depend.ng on 
which service is used, a server either directly relays the message to the 
10 recipient or facilitates a direct connection between the sender of a message 
and the recipient. In Figure 1. communication between IM clients 100 .s 
facilitated by presence server 102. In order to communicate with other 
instant message clients, subscribers send registration messages to 
presence server 102. The registration messages may contain contact 
15 information for IM clients 102. A proposed presence protocol for performing 
registration and subscription services will be discussed in more deta.l below. 

IM services typically employ one of three means to move messages 
around: a centralized network, a peer-to-peer connection, or a comb.nation 
of both, in a centralized setup, users are connected to each other through a 
series of data servers. Such servers effectively form a wide area network 
(WAN) Consequently, when an instant message is sent by a subscnber. at 
Lst one of the data servers finds the intended recipient's PC address and 
routes the message through the network until it reaches its destinabon. 

,n the peer-to-peer approach, a central server maintains a database 
of online subscribers and their associated Internet Protocol addresses. After 
a subscriber logs in. such a server sends the subscriber the IP addresses of 
everyone on their contact list who is also currently logged on. 

When a subscriber wishes to send an instant message to another 
user the subscriber's client sends the IM directly to the user's client, without 
30 involving the server. As such, all IM message traffic does not necessarily go 
' ' through the entire network. Such an architecture tends to result in improved 
network performance, as compared to other IM schemes. 
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A „ extent discussion of a proposed presenca pre-oc*. canbe 

teu „d in an M Engineedn, ™ P- ^ « ^ 

The Presenoe Mart/ ,n»rne W ra«.seres»at.presenoep ro tocoU)O.W. 

^uTa 1999. •- **•» - *** 15 lnOTP ° ra,ed h " Wn ' 
etZ in Its en*.,. in - P«*- — 
presence server is defined as a server mat manages mfomnaoon 
LTco^on of en««es. subsets fo those en««e, and _ pnvaoy 

'^Z server has an address a, whid, presence messages may be 
defivered. Presence informal is defied in ihe proposed p^enc. mm 
plco, specification as initio, so* as presenoe status, ourren. p«n, 
o, present (if an*, m «me. etc. ^ an en,,. As osed herein, <he, n, 
presenoe information refers to an, infection regarding an end user or 
Z induding. but not fimited to: end ueer fccaffcn, end user stofus. medra 
^Is o, a tefcpnonv gafewav assodated * ft. end use, end use, 
directory number, end user IP address, etc. 

I en«y has oonW over pobfcadon of He presence rnfonnaton. An 

anta, . deJd as me * e.g. a person, on — 
infcmata is being maintained. Each en«ty bee a un«ue ha* l*e 
ld en.ity of .he presence server maintaining presence rtomtatron for to 
2T«. be dlmine, .mm .be handie. A handie is we» Known name,* 
an aW An exampie o, a handie is P p:, taW w.in tera »a.a«.c«n^an.Ran- 
C,, y a poin. o, presence <PoP> is downed as a point * - 

entity ifanendtyispresenUisconrardedtoonePoP. 6a *^ PteSa " 
Tmss. e g., an ,P address and a pod number, a. which presence 

messages may be delivered. . 

A W icai exemple o. how me presence protocol may be used 
Mews An en% A oonneded .0 an endpoin. E may subscdbed through a 
Itn'oe server P .o another end* B. When ft. status o. B changes, P - 
presence setver r specifications allow. If P 

notify E of ttre change in status of B. if Bs pnvaoy v Dm 
» Z*** to no«y E. for instance, because E is unreachabte. P mad« Eas 
JZ and will sobseoueney not ademp, .o deiiver «o E undl E reestabiishes 
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„ in arWon. P -ay periodically pin, an »ndpoinl *» «""* 

stored al me server is current. 

once presence information about an entity is delivereo 
5 Once pre* protoco|s (or 

endpoint. the endpoint may directly con 

exohenging instant messages, file transfer, etc. „,„. 
are not defined in toe ebove-referenced presence ^ 
Uiy, the P..OCO, used tor - - J- - - 

10 oeMe the scope o. me presence protoa* spe*a 

.ranspon pro,o», used to deWer ^^pre^n* ' 
registration and update messages is not defined tn » 

toe, pre^e ftr M* messaging (.M, and preeanca seorices w«un toe 
3„ operation invokes toe £ — *j£ ^ t- 
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„ -presence," * Interne, -* » - ^ flC^e 

H^ver as communication netwodtlng technology has earn* » «*• 
n id pace, so have .ha means by which end users or subset.*- 
tunicate. More pa^dy. - — 01 ^ 

5 wireless commute terminals, «* - «* ^ £ 
phones, and persona, dig«a, assist has led » a 
efwo^ng or inter-medium communion soWons. ,n «. 
repidty becoming useful for a subscdber to have <he,r wtreless phones^s 
^"presence- Known to other subscribers, where .hese onte, sub*,** 

10 1, be using a variety o, o— — - -« 

J*m wired phone ser*ce. shod message setvtce (SMS), or interne. 

SerViCe A , present, such date ****** P— «— * "* 
ad J « implemented o, these services w»in a 
sled Tetephone Ne,wo* (PSTN) en*onmen, Agar, - £ 
continuing movement towards the convene, of date and telephony 
^ there exlste the need to put* a system and method o, £». 
In, messaging and presence services * a «— 

Til. MM what is needed is an msten, messagmg I presence 
m „del for us. in a convened date and telephony networtc 

rwK ^iirenf t he Invention 

According to one aspect, ate ptesen, invention includes a presence 
° , ^ The oresenoe registration and routing node 
registration and roubng node. The presence reg tek>ohon y- 
receives a signaling system 7 (SS7) message ,n responae to a tetephony 
ZL a*n «* as me acavalon o. a mobite handset, ate - • 
Zl number to estebllsh a call, or me enfty of predetemttned OTMF 
d r . Cna. te - SS7 message. ft. presence re*s«on an 

presence in.omra.on regarding an end use, in a presence 
The presencs-se^ncompaUbte message may be In any preaence-server 
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compel ton**, m*d,ng session IW P«— (S.P) pre«n». s£ 
Lent «M - presence profoco, (IMPP). S>P . defined . RFC 
^TstP: Session InMon Protocol (March ,999). the --«-» -** 

rip— ^ py — * * — * impp - r^c 

zn. A Mod,, for MM Messaging. (February 2000, and . 
"2. Message / Presence Pmtoco, foremen* 
dfed osures o. each o, which a. incarporated here* * J- 
««* Presence is defined in a vanety of documents, .ncfudmg .he IETF 
12 d a„ menttoned above and oarer IETF decent M - b. 
Ha below. The presen, — is no, intended ,o he to aw 
^ presence protoco, torn*. The formate dtscuss* 
lnp.es of presence protoco, formate suHabte tor use w„h I. P-en. 

lncW es an advanced database communications modute (ADCM) to 
r ^ng ouehes for presence infomrafion. The ADCM modu,e towards to 
Z fo a presenc, appf^o, su* as a S,P. ,MPP. or present 
ZLn -m presence app,,c*n tormuiates a presence^ - 

-ssage. for^s fhe P™™—^^ 
. presence datobase. receives a response from are 
H response to .he ADCM modute «o be sen. to .he reouesfor ov* an ,P 
The presence datebase may be interna, or extern* to toe 
oresence registration and routing node. 

' " me aspecte of fhe invent - be ex^ained in terms - mod*, 
end orocesses ,. is understood mat these modules or processes may be 
: JZteTin hardware, software, or a —on o. 
JLre. Exemplary hardware upon whtoh me processes and rnrites 
Hbed betow may execute indudes a miooprooessor. su*as an Into 
P^um* processor and assorted memo*. Each of me modules ■ 
pll egtefrafion and rou*g node a^ to ate present 
Tb. a P nted droui. beam v* a mtoroprocessor and memo,, located 
IS The miooprocesaor may execte one or more compute, programs 
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W per.om*g me presence region and roudng funcdons discuss* 

^ Accord.*,. » * an ob*ct 0, the present — ,0 ^ a 
presence relation and routing node for receiving SS7 messages in 
s ^ to tele^ated aeons a* MM*. P™server- 
oompatibte messages in response to the SS7 messages. 

„ is another obiec. 0. the preeen. invent to provrfe a presence 
registration and muting node tor receiving Internet Protocol (IP) 
rCatod SS7 messages in response to to > -« - 
,„ .emulating presence-server-compadble messagee In response to me SS7 

another obiec, o. the present invendon to provide a presence 
registradon and toudng node cspable 0, routing presenc^n«r<ompa« 
nlsages to a presence database and forwarding responses from the 

a k Hatahase over an IP network. 

Tie another object o. the present invendon to provide a presence 
regisuedon and routing node dta, Modes an internet or integrated presence 

"T* anodter obiec, o, «he present inventton to provide a presence 
20 regisdadon end roudng node dte. is adapted to maintain a— or btdtn, 
inlormadon related to presence database access. 

p ri .< Qejcrj Bljgn c * nrawinos 
Purred embodiments of the invendon wilt now be explained with 
referencetotheeccompanyingdrawingsofwhich: 

Figue t is a btoc* diagram illustradng convendona, presence and 
instant messaging message flow, 

Figure 2 is a block diagram of en SS7/IP gateway that ma, be 
MM .0 penorm presence message processing ac<»rd,ng to 
30 embodiments of the present invention; 

Figure 3 is a bloc* diagram of a presence region and rout»r, 
node according to en embodiment of the present invent™.; 
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Figure 4 is a bio* diagram of a presence registration and roubng 
„ode according to an embodiment of the present im/entron; 

sa and 5b are a «ew chad MM. exemplary steps M 
m ay be formed by a presence r.g,sb*n and roubng node ,n process 
an AMmessageacccrdingtoanembodimentofmepresentrnventon, 

6 is a biocK digram ii.us.adng SCCP encapsutabon of an 

,sup r;rrr : a ^ — ■ -» - -» 66 

performed by a presence registrar and roudng nod. in pmcessmg a 
TCAP m«sage ac«ding to an embodiment of «re present invenbon, 

Ftgure 8 is a bloc* digram illuslrabng the operate of a pre*r~ 
, and roubn, node in a mobile teiecommunfcabons network 

according to an embodiment of the present invention; 

Figure 9 is a block digram illustrating the operabon of a presence 
nation and «*, node in proces*g an ,AM message according to an 

embodiment of the present invention; „ r «ence 
Figure 10 is a bio* diagram illustrating the operabon of a presence 
.egisbatl and roubng node for in process** a TCAP message accordrng 
to an embodiment of the present invention; 

Figure 11 is a bloc* diagram of a presence regtstrabon and routing 
node including an internal presence dafcbase according .0 an embody. 

°*C'™T™ chad lining exempt slops tha, ma y be 
perfoJt by me presence registrar and roubng nCe illustrated in *gure 
T« responding to a presence guery fo, updabn, present* s^naabon 
according to an embodiment of the present invenbon; 

Ffcure 13 is a biocK diagram o, a preface reg*babon aa« 
^ including an externa, presence database according to an embodrmem 

acoordinl to an embody, of ft. praaen. invenbon that mdudea a 
message accounting and billing subsystem; 
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Figure 15 is a table that illustrates a sample usage and 
measurements database associated with a message accounting and bilhng 
subsystem of the present invention; and 

Figure 16 is a block diagram of a presence registration and routing 
according to an embodiment of the present invention that includes a 
presence database and message accounting and billing subsystem. 
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rifttailftri Desc ription of the Invention 
The present invention includes a presence registration and routing 
(PRR) node for communicating with and routing messages between both 
internet Protoco. (.P) and Signaling System 7 (SS7) network nodes In one 
embodiment, a PRR node employs an interna, architecture similar to that of 
high performance STP and signaling gateway (SG) products wh,ch are 
marketed by Teke.ec, Inc., of Cafcbasas, Ca.ifornia as the Eagle STP and 
,P> secure Gateway-, respectively. A block diagram that generally 
i„ustrates the base interna, architecture of the Eagle® STP product is shown 
in Figure 2. A detailed description of the Eagle' STP may be found in the 
Eagie* Feature Guide PN/91 0-1 225-01, Rev. B. January 1998. published by 
Teke.ec. the disdosure of which is incorporated herein by reference nr nts 
entirety. Simiiany. a detai.ed desertion of the .P* Secure Gatewa may 
be found in Teke.ec pub.ication PN/909-0767-01 , Rev B. August 1999 
entitled Feature Notice ,P' Secure Gate^ ****** *. 
which is incorporated herein by reference in its entirety. The speafic 
functional components of an IP 7 Secure Gateway- for transmitting and 
receiving TCAP messages over an Internet Protocol (IP) netivo* .m 
described in commonly-assigned, co-pending Internationa. Patent 
Publication No. WO 00/35155. Published June 15. 2000. the disdosure of 
which is incorporated herein by reference in its entirety. As describe .n me 
above referenced Eag,e« Feature Guide, an Eagfc' STP 250 indudes the 
foHowing subsystems: a Maintenance and Administration Subsystem (MAS) 
252 a communication subsystem 254 and an application subsystem 256. 
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MAS 252 provides maintenance communicate., initial program load, 
patera, services, aiarm processing and system d,*a. Common 
^system 254 inoMe. an ln.erpmc.ssor Message Transport OMT) *» 
„ is me main communication bus among all subsystems „ me Eagle 
STP 250. This bigh-speed communications system functions as .wo 125 
Mbpscourter-rotating serial buses. 

Applicator subsystem 25. includaa applioabon cards that are 
ra pap te - communing w»h me other cards through -» ,,MT buses. 
Numerous types of applicedon cards can be mco^orated * «. 
deluding: a LinK Intertaca Module (LIM) 250 that proves » -* 
Zb links and an Appfcadon Sa^ce Module (ASM) 202 Ore, p*£££ 
« — n. geteway screening and other services. A Tn^ate 
Service Mod* (TSM) 204 may also be proved .0 export tng^d ^1 
oumb er portable se^ce. Once again, a deteited desenpbon of th. Ea*. 
; sTP is provide in the above a.ed Eagto' ftafcr* Guide and need not be 
^bert in date,, herein. With pedicular regard to th. ^»ng gateway 
SG , product line pmduced by TeKefec . should atao be apprea-ed . 
Z Lmunicadon Module <DCM, 200 can be employed to ^ N 
*ansport of Interne. Protocol (IP) encapsulated SS7 messages over an 

Gateway- Refease 1.0 publicadon. WKh farther regard » ft. TSM 0^ 
LNP services modute mentioned ebove. a deteiled deacnpte.no, me Tetetec 
Wgg ered LNP solution may be found in «» Mff Gu.de LfVP UM8 
ZC109M1; Rev. A. January 1090. published by TeKetec. ma 
26 lire of whir* * hereby inoo^ated 

Furthermore, systems end methods for providing tnggedesa LNP 
LnTcZ wll a ne^ routetg node are described In co.moniy- 

14 ^0. me dlsdosure of wbl* is incited herein by reference in Ite 
30 entirety. 



_ PCT/US01709195 
WO 01/72055 

-11- 

ftS7 MSU Triggered Presen t Registration Mpc^age Generation 
Shown in Figure 3 is a schematic diagram of a presence registration 
and routing node 300 of the present invention. It will be appreciated that 
presence registration and routing node 300 includes a high speed 

5 interprocessor Message Transport (IMT) communications bus 310. 
Communicatively coupled to IMT bus 310 are a number of distributed 
processing modules or cards including: a pair of Maintenance and 
Administration Subsystem Processors (MASPs) 312. an SS7-capable Link 
Interface Module (LIM) 320. an IP-capable Advanced Data Communication 

10 Module (ADCM) 360. and a Presence Registration Module (PRM) 340. 
These modules are physically connected to the IMT bus 310 such that 
signaling and other type messages may be routed internally between all 
active cards or modules. For simplicity of illustration, only a single LIM 320, 
ADCM 360. and PRM 340 are included in Figure 3. However, it should be 

1 5 appreciated that the distributed, multi-processor architecture of the presence 
registration and routing node 300 facilitates the deployment of multiple LIM, 
ADCM. PRM, and other cards, all of which could be simultaneously 

connected to the IMT bus 310. 

MASP pair 312 implements the maintenance and administration 
20 subsystem functions described above. As the MASP pair 312 are not 
particularly relevant to a discussion of the flexible routing attributes of the 
present invention, a detailed discussion of their function is not provided 
herein. For a comprehensive discussion of additional MASP operations and 
functionality, the above-referenced Tekelec publications can be consulted. 
25 Focusing now on LIM card functionality, it will be appreciated that LIM 

320 is comprised of a number of sub-component processes including, but 
not limited to; an SS7 MTP level 1 process 322. an SS7 MTP level 2 process 
324. an I/O buffer or queue 325. a gateway screening (GWS) process 326. a 
Presence Registration Request (PRR) stop action process 328. an SS7 MTP 
30 level 3 layer HMDC process 330. and an HMDT process 332. MTP level 1 
and 2 processes 322 and 324, respectively, provide the facilities necessary 
to send and receive digital data over a particular physical media / physical 
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interface, as well as to provide error detection / correction and sequenced 
delivery of all SS7 message packets. I/O queue 325 provides for temporary 
buffering of incoming and outgoing signaling message packets. GWS 
process 326 is responsible for examining the incoming signaling message 
5 and determining which, if any. of the provisioned stop actions are applicable. 
PRR stop action process 328 is responsible for making a copy of. and 
subsequently encapsulating, an incoming SS7 ISDN User Part (ISUP) IAM 
signaling message packet within an SS7 Signaling Connection Control Part 
(SCCP) formatted packet. It should be appreciated that PRR stop act.on 
10 process 328 could also be configured to simply encapsulate the original 
incoming SS7 ISUP IAM signaling message, without making a copy. MTP 
level 3 HMDC process 330 receives signaling messages from the lower 
processing layers and performs a discrimination function, effectively 
determining whether an incoming SS7 message packet requires internal 
15 processing or is simply to be through switched. For instance, in the case of 
an SS7 TCAP message associated with presence registration or an SCCP 
encapsulated ISUP IAM message. HMDC process 330 would determine that 
the message should be internally routed for further processing. HMDT 
process 332 manages or directs the internal routing of SS7 message 
20 packets that require additional processing prior to final routing. Once again, 
it should be appreciated that a LIM card may contain more functional 
processes than those described above. The above discussion is limited to 
LIM functionality associated with the basic processing of in-bound signalmg 
messages. 

25 As such, it will be appreciated that the three functional processes 

associated with an Advanced Data Communications Module (ADCM) 360 
shown in Figure 3 are simply those processes that are relevant to a 
discussion of out-bound ADCM operation in the examples of PS routmg 
node operation disclosed herein. Furthermore, it will be appreciated that 

30 ADCM 360 is similar in function to the DCM application module described 
above In the case of ADCM 360. the message packets processed by the 
card need not be native SS7 type messages that have been encapsulated in 
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an IP packet Instead, the ADCM 360 is capable of processing, transmitting, 
and receiving both native SS7 and native IP protocol messages. 

The processes explicitly shown on the out-bound ADCM 360 include 
an I/O queue 362 and IP level 1 and 2 processes 366 and 364, respectively. 
5 I/O queue 362 facilitates temporary buffering of incoming and outgoing 
signaling message packets, while IP addressing operations are performed 
by the IP level 1 and 2 processes 366 and 364, respectively. 

Once again, the description of LIM and ADCM sub-components 
provided in the above description is limited to those sub-components that are 
10 relevant to the sample implementation scenarios discussed herem. For a 
comprehensive discussion of additional LIM and ADCM-type operations and 
functionality, the above-referenced Tekelec publications can be consulted. 

In general, a PRM card includes the database and database control 
processes necessary to achieve the presence registration message 
15 generation and routing functionality of the present invention. The PRM 340 
shown in Figure 3 is comprised, in part, of an SCCP subsystem controller 
known as a Signaling Connection Routing Controller (SCRC) process 342, a 
Presence Registration Manager (PRMG) process 344. and a number of 
Presence Registration Applications generally indicated by the numeral 346. 
20 Included among the Presence Registration Applications is a session inrt.at.on 
protocol (SIP) registration application process 348 for generating SIP 
messages, forwarding the SIP messages to a presence server, and 
processing SIP messages received from the presence server. The format 
for SIP messages is described in detail in the above-referenced RFC 2543, 
25 which defines the SIP protocol. In addition, the portion of a SIP message 
that carries the media capabilities information for an end user dev.ce .s 
referred to as the session description protocol portion. The sesston 
description protocol is described in detail in RFC 2327. "SDP: Session 
Description Protocol." (April 1998). the disclosure of which is incorporated 
30 herein by reference in its entirety. 
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Presence protocol process 349 may also be included for 
communicating with a presence server using the messages described in the 
above-referenced presence protocol specification. 

Instant messaging and presence protocol (IMPP) process 351 may 
5 also be included for communicating with a presence server according to the 
IMPP protocol. The IMPP protocol is described in detail above and in one 
or more of the following IETF Internet Draft documents: 

•Message Information Data Format," <draft-ietf-impp-midf- 
01.txt>, January 19, 2000; 
10 'Presence Information Data Format for IMPP," 

<draft-ietf-impp-pidf-01.bd>. March 10. 2000; and 
"Transport Protocol for Presence Information/ Instant 
Messaging," <draft-ietf-impp-pitp-mitp-01>, March 9, 2000, 
the disclosures of each of which are incorporated herein by reference in their 
15 entirety. 

The present invention is not limited to communicating with a presence 
server using SIP, IMPP, or presence protocols. Any protocol for 
communicating with a presence server is within the scope of the invention. 
SCRC process 342 is responsible for discrimination of signaling 

20 messages at the SCCP level, and for distributing the signaling messages to 
an appropriate higher processing level application or function. In the 
configuration shown in Figure 3, the next highest processing level is 
represented by the PRMG process 344. PRMG process 344 is responsible 
for determining how to process the incoming message packet. For instance. 

25 if the message packet contains an SCCP encapsulated ISUP I AM message, 
PRMG process 344 is configured to de-capsulate the original ISUP IAM 
message, and subsequently extract the appropriate information necessary 
for further processing from the de-capsulated message. However, if the 
incoming message were a TCAP formatted packet, no de-capsulation action 

30 would be required. In either case. PRMG process 344 is also charged with 
determining which of the provisioned presence registration applications is 
required for successful processing of a particular incoming signaling 
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message packet. As will be appreciated from Figure 3. a number of 
presence registration applications may be simultaneously provisioned on a 
single PRMG card. These presence registration applications may be 
configured such that each application is capable of generating presence 
5 registration messages that are formatted in different protocols including, but 
not limited to. SIP, IMPP. and presence protocol. 

While any of the above-described presence registration applications 
may be provisioned on a single PRM card, SIP registration application 348 is 
used in the examples described herein to illustrate the functionality of the 
10 presence registration and routing node in updating presence information in a 
presence server database and obtaining presence information. SIP 
registration application 348 essentially contains the logic necessary to 
process the incoming SS7 message and construct the appropriate SIP- 
formatted presence registration message. 
15 Shown in Figures 3 and 4 are system level diagrams of one 

embodiment of presence registration and routing node 300 of the present 
invention. Also indicated in both figures are general message flows 
associated with the processing of incoming SS7 signaling packets and the 
generation of outbound presence registration messages. More particularly. 
20 Figure 3 illustrates the message flow associated with an incoming SS7 ISUP 
IAM message, while Figure 4 indicates the message flow associated with an 
incoming SS7 TCAP message. A detailed flow chart of the major steps 
associated with one particular implementation of the SS7 triggered presence 
registration message generation process is presented in Figures 5a and 5b. 
25 and may be used in conjunction with the schematic diagram shown in Figure 
3 to better understand the ISUP IAM based presence registration message 

generation methodology. 

Refening to Figure 5a. in step ST1. an incoming ISUP IAM message 
is received at the inbound LIM module 320. In steps ST2 and ST3. the 
30 incoming ISUP IAM message is received and processed by the MTP Level 1 
and 2 processes 322 and 324, respectively. With MTP Level 1 and 2 
processing complete, the signaling message packet is temporarily buffered 
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in the I/O queue 325 before being passed up the stack to the MTP Level 3 
Gateway Screening (GWS) process 326. As indicated in step ST4, GWS 
process 326 examines the incoming ISUP IAM message and determines not 
only whether the message is to be allowed into the switch for further 
5 processing, but also which, if any, of the provisioned stop actions are 
applicable to the incoming message. In this example, GWS process 326 
examines the incoming ISUP IAM message and determines that the 
message is permitted to enter the switch. Furthermore, upon examination of 
the Originating Point Code (OPC), Destination Point Code (DPC) and 
10 Service Indicator Octet (SIO) fields contained in the MTP routing layer, it is 
determined that the message requires additional processing by the PRR 
stop action 328 (ST5). In steps ST6 PRR stop action process 328 receives 
the ISUP IAM message from GWS process 326 and determines that the 
incoming message is an ISUP type MSU. The PRR stop action process 328 
15 next checks the DPC of the incoming MSU. More specifically, the PRR stop 
action verifies that the DPC of the incoming MSU is a valid PC. PRR stop 
action 328 examines the incoming MSU to determine whether presence 
registration service is required. If the incoming MSU is identified as being an 
ISUP IAM type message, PRR stop action 328 encapsulates a copy of the 
20 ISUP IAM message within an SCCP formatted MSU. as indicated in step 
ST6. Such SCCP encapsulation is effectively achieved by adding essent.al 
SCCP message leading and trailing bit sequences to the base bit sequence 
that comprises the ISUP IAM MSU. as generally illustrated in Figure 6. 
Thus, an SCCP type encapsulated MSU is created which envelops or 
25 contains an ISUP type MSU. Subsequent to this encapsulation, the 
incoming message no longer appears or is treated as an ISUP IAM message 
within the presence registration and routing node 300. but is instead 
processed internally as an SCCP type SS7 message. 

Unless additional processing by an unrelated subsystem is required. 
30 the original ISUP IAM MSU is then routed directly to HMDC process 330 
where normal ISUP MSU type routing is resumed. However, once again, it 
should be appreciated that the original ISUP IAM MSU could be SCCP 
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encapsulated and further processed instead of producing a oop» of me ISUP 
MSU. It should also ba appraciatad thai fallura of tha incoming ISUP MSU 
„ maa. «ha cnteha specified in step causaa .ha original. 
MSU to ba routed directly to HMDC ptocaas 330 whara normal ISUP MSU 

type routing is resumed. 

However. In tha cas, whara an incoming ISUP MSU aattate. tha ST5 
chtaha, SCCP angulation o, tha ,SUP MSU occra and tha rested 
ancapaulatad MSU is ducted to HMDC process 330 (ST7). whana SCCP 
^ process** ia parfotmad. In Ota exampfe sbown in F*u» 3JM0C 
procaas 330 axaminaa Ota message packet and da.arm.naa MM DPC 
and Subsystem Number (SSN) of the SCCP packet la .he PC of ma 
presence region and roubng node. Coneeguently, What PM< 
L SCCP MSU within Ota roubng node ia assumed to ba neceaaary, and Ota 
packet ia pass* to .ha HMDT prcoaaa 332. The HMDT process 332 
, examines ft. Secice Indicator (SI, Oeld o, me ancapaulatad HSU.* 
Wca.es M the encapsula«ng packet la of an SCCP As such^MCT 
process 332 places .ha encapsulated SCCP MSU on h,gh spaed IMT bus 
,10 fo, transport » PRM 340 and subsequent presence 4M» ■ 

Refemng to Figura 5b. I. stop ST., the encapsulated SCCPMSU«t 
„ received and examined by SCRC process 342 that is resident on PRM 340. 
SCRC process 342 examines me messaga. datemtlnas that 
registrar service is indicated, and towards the erxapsulatedMSU to the 
PRMG process 344. as indeed by step STO. In step ST10 PRMG 
pr^aes 344 exiraote Ote ISUP 1AM MSU from the *CCP enve ope and 
25 detennines that ma ISUP MSU requires me generation of a S,P-fom»«ed 
praeanca registrar massage (ST11). T* fSUP 1AM MSU . so eague^y 
directed to SIP application 34. lor further processing (ST12). JMP 
appiicata 34. examines the ISUP IAM MSU and. using tnfbrm^on 
oLnad wimin the MSU. generates a S,P-forma«ed present region 

30 — famm complete , the slP *rma«ad presence 
regisWon massage Is passed to HMRT process 350. HMRT process 350 
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determines to which ADCM card the SIP registration message packet should 
be routed for subsequent outbound transmission (ST14). In this case, the 
HMRT process 350 determines that the desired outbound signaling link 
associated with the routing of the SIP registration message is located on 
5 ADCM 360. Consequently, the SIP message packet is internally routed 
across the IMT bus 310 to LIM 360. where it is received by the I/O queue 
process 362 (ST15). Eventually, the modified message packet is passed 
from the I/O queue 362 on to the IP Level 2 and Level 1 processes 364 and 
366. respectively (ST16). Once again. IP level 1 and 2 processes 366 and 
10 364. respectively, provide the facilities necessary to send and receive d.g.tal 
data over a particular physical media / physical interface, as well as to 
provide error detection / correction and sequenced delivery of all IP message 
packets transmitted into the IP network. As indicated in step ST17. the SIP- 
formatted presence registration message is then transmitted into an IP 
15 network for ultimate delivery to and use by a presence database system. 

It will be appreciated that the registration message generation 
methodology shown in Figure 4 is fundamentally similar to the process 
indicated in Figures 5a and 5b. The primary difference involves processing 
variations that result from the handling of SS7 ISUP versus SS7 TCAP type 
20 messages. Most notably, since a TCAP message is. in fact, also an SCCP 
message, there is no need to directly encapsulate or copy and encapsulate 
the incoming TCAP message. Instead the TCAP message is simply directed 
from the inbound LIM 320 to the associated PRM 340 via the high speed 
IMT Bus 310. in much the same manner as the SCCP encapsulated ISUP 
25 I AM described in detail above. As such. Figure 7 presents a flow chart of the 
major steps associated with the processing of a TCAP-type presence 
registration request message, which may be used in conjunction wrth the 
schematic diagram shown in Figure 4 to better understand the TCAP based 
presence registration message generation methodology. 
30 With particular regard to the scenario generally illustrated in Figure 4. 

an incoming TCAP-formatted presence registration request message is 
received at the inbound LIM module 320 <ST1). Once again, in steps ST2 
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and ST3, the incoming TCAP message is received and processed by the 
MTP Level 1 and 2 processes 322 and 324, respectively. With MTP Level 1 
and 2 processing complete, the signaling message packet is temporarily 
buffered in the I/O queue 325 before being passed up the stack to the MTP 
5 Level 3 Gateway Screening (GWS) process 326. As indicated in step ST4, 
GWS process 326 examines the incoming TCAP message and determines 
not only whether the message is to be allowed into the switch for further 
processing, but also which, if any. of the provisioned stop actions are 
applicable to the incoming message. In the scenario shown in Figure 4, 
10 GWS process 326 examines the incoming TCAP message and determines 
that the message is permitted to enter the switch; Furthermore, upon 
examination of the Originating Point Code (OPC). Destination Point Code 
(DPC) and Service Indicator Octet (SIO) fields contained in the MTP routing 
layer, it is determined that the message does not require additional 
15 processing by the PRR stop action 328. As such, the TCAP MSU is then 
routed directly to HMDC process 330 where SCCP type processing is 
performed (ST5). In the example shown in Figure 4, HMDC process 330 
examines the message packet and determines that the DPC and Subsystem 
Number (SSN) of the TCAP packet is the PC of the presence registration 
20 and routing node. Consequently, further processing of the TCAP MSU 
within the routing node is assumed to be necessary, and the packet is 
passed to the HMDT process 332. The HMDT process 332 examines the 
Service Indicator (SI) field of the TCAP MSU, which indicates that the packet 
is of an SCCP type. As such. HMDT process 332 places the TCAP MSU on 
25 high speed IMT bus 310 for transport to PRM 340 and subsequent presence 

registration service. 

In step ST6. the TCAP MSU is received and examined by SCRC 
process 342 that is resident on PRM 340. SCRC process 342 examines the 
message, determines that presence registration service is indicated, and 
30 forwards the TCAP MSU to the PRMG process 344. As indicated in step 
ST7, the content of the TCAP message is examined to determine whether 
the TCAP presence registration request requires the generation of a SIP- 
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formatted message. In this example, it is assumed that the TCAP 
registration request message requires a SIP-formatted response and as 
such is subsequently directed to SIP application 348 for further processmg. 
SIP application 348 examines the TCAP MSU and. using information 
5 contained within the MSU, generates a SIP-formatted presence registration 
message (ST8). 

With SIP processing complete, the SIP-formatted presence 
registration message is passed to HMRT process 350. HMRT process 350 
determines to which ADCM card the SIP registration message packet should 
10 be routed for subsequent outbound transmission (ST9). In this case, the 
HMRT process 350 determines that the desired outbound signaling hnk 
associated with the routing of the SIP registration message is located on 
ADCM 360. Consequently, the SIP message packet is internally routed 
across the IMT bus 310 to LIM 360. where it is received by the I/O queue 
15 process 362 (ST10). Eventually, the modified message packet .s passed 
from the I/O queue 362 on to the IP Level 2 and Level 1 processes 364 and 
366, respectively (ST11). As indicated in step ST12. the SIP-formatted 
presence registration message is then transmitted into an IP network for 
ultimate delivery to and use by a presence database system. 
20 Shown in Figures 8, 9 and 10 are simplified network diagrams that 

illustrate example implementations of the embodiments described above. 
More particularly. Figure 8 illustrates an implementation of the presence 
registration and routing node 300 of the present invention in a mobile or 
wireless telecommunications environment, generally indicated by the 
25 numeral 400. Network 400 includes a mobile subscriber 402, a base station 
complex 404. a mobile switching center (MSC) 406, a home location reg.ster 
(HLR) 408, and a presence server 410. It will be appreciated that the 
message flows shown in Figure 8 indicate that the presence registration and 
routing node 300 formulates and transmits a presence registration message 
30 416 in response to the receipt of a location update message 412 that is sent 
from the MSC 406. Those skilled in the art of wireless telecommunications 
will appreciate that an MSC performs a number of functions in a wreless 
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network, including the formulation and routing of signaling messages. In the 
example shown in Figure 8, the location update signaling message used by 
the presence registration and routing node 300 to trigger the presence 
registration message 416 is destined for the HLR node 408. In such a 
5 wireless scenario, the presence registration message 416 could be 
formulated and transmitted by the presence registration and routing node in 
response to a mobile location update message associated with the 
registration of a wireless customer in a particular cell or service area. Once 
again, those skilled in the art of wireless or mobile telecommunications will 
10 appreciate that wireless or mobile signaling messages are generated and 
transmitted within a wireless network in response to the powering-up or 
tuming-on of a customer's wireless phone, as well as in response to .nter- 
cell movement of a mobile subscriber during the course of a mobile call. As 
such, the presence registration and routing node of the present invention 
facilitates a method of presence registration that is completely transparent to 

the cell or mobile phone user. 

Figure 9 illustrates an implementation of the presence registration and 
routing node 300 of the present invention in a wired telecommunications 
environment, generally indicated by the numeral 420. Network 420 includes 
a wireline subscriber 422. an end office (EO) 424. and a presence server 
426 It will be appreciated that the message flows shown in Figure 9 mdicate 
that the presence registration and routing node 300 formulates and transmits 
a presence registration message 434 in response to the receipt of an ISUP 
call signaling message from the EO 424. More particularly, the presence 
registration message 434 is generated in response to the receipt of an ISUP 
initial Address Message (IAM) message 428. Those skilled in the art SS7 
signaling will appreciate that an ISUP IAM message is the first in a sequence 
of ISUP formatted SS7 call control signaling messages that are requ.red to 
complete a phone call in the Public Switched Telephone Network (PSTN). 
As such, it will be appreciated that in the scenario illustrated in Figure 9. the 
presence registration message 434 is formulated in response to an attempt 
by the wireline subscriber 422 to place a telephone call. As presence 
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registration message generation is triggered by an ISUP 1AM message, itwill 
be appreciated by those skilled in the art of SS7 telecommunications that 
completion of an attempted telephone call is not required in order for a 
presence registration message to be generated and transmitted to a 
5 presence server. Thus, any call attempts by wireline subscriber 422 w.ll 
effectively register the subscriber's presence with presence server 426 v.a 
presence registration and routing node 300 of the present invention. It w.11 
also be appreciated from Figure 9, that the triggering ISUP .AM message 
428 is subsequently routed as normal, on to a destination address specrfied 

10 in the message. 

Shown in Figure 10 is a variation of the scenario that was .Hustrated ,n 
Figure 9 whereby an SS7 signaling message used to trigger the formulation 
and subsequent transmission of a presence registration message .s 
comprised of a TCAP-type message . instead of an ISUP-type message. 
16 Shown in Figure 10 is an implementation of the presence registrat.cn and 
routing node 300 of the present invention in a wired telecommunications 
environment, general.y indicated by reference numeral 440. Network 440 
includes a wireline subscriber 442, an end office (EO) 444. and a presence 
server 446 In the particular embodiment shown in Figure 10. it is assumed 
20 that wireline subscriber 442 indirectly initiates a TCAP message 448 by 
dialing "88" or a similar code on a telephone keypad. Once aga.n. those 
skilled in the art of SS7 telecommunication networks will appreciate that 
generation of such TCAP messages is accomplished by an End Office <EO) 
or Service Switching Point (SSP) in response to the "88» keystrokes, as 
25 generally indicated in Figure 10. As such, by dialing "88" wireline 
subscriber 442 is effectively manually registering their presence w.th the 
presence server via the generation of the TCAP message 448. which in turn 
causes the generation of a presence registration message 450 by the 
presence registration and routing node 300 of the present invention. 
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jP^q ratPri Presence p atahase System 
The embodiments of the present invention described in detail above 
can be easily extended to include a presence registration and routing node 
that is capable of maintaining a presence database system. One 
embodiment of such a presence registration and routing node is illustrated .n 
Figure 11. and generally indicated by the numeral 500. It will be appreciated 
that in the particular embodiment presently contemplated, presence 
registration messages are not formulated and routed from the node, but 
instead presence registration takes place at or within the node. That ,s, .n 
the embodiment of the present invention shown in Figure 11 and generally 
discussed below, the functionality of a presence server is generally included 
within the presence registration and routing node 500. 

With particular regard to the embodiment illustrated in Figure 11 and 
in a manner similar to the embodiment described above, it will be 
appreciated that presence registration and routing node 500 includes a h,gh 
speed Interprocessor Message Transport (IMT) communications bus 310. 
Communicatively coupled to IMT bus 310 are a number of distnbuted 
processing modules or cards including: a pair of Maintenance and 
Administration Subsystem Processors (MASPs) 312. an SS7 capable L,nk 
interface Module (LIM) 320, an IP capable Advanced Data Communion 
Module (ADCM) 360. and a Presence Database Module (PDM) 502. These 
modules are physically connected to the .MT bus 310 such that signaling 
and other type messages may be routed internally between all active cards 
or modules. For simplicity of illustration, only a single LIM 320. ADCM 360. 
and PDM 502 are included in Figure 11. However, it should be appreciated 
that the distributed, multi-processor architecture of the presence reg.strat.on 
and routing node 500 facilitates the deployment of multiple LIM. ADCM. 
PDM. and other cards, all of which could be simultaneously connected to the 

IMT bus 310. . 

As in the previously described embodiment, MASP pair 3iz 
implement the overall maintenance and administration subsystem functions. 
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For a comprehensive discussion of additional MASP operations and 
functionality, the above-referenced Tekelec publications can be consulted. 

Once again, it will be appreciated that LIM 320 is comprised of a 
number of sub-component processes including, but not limited to: an SS7 

5 MTP level 1 process 322, an SS7 MTP level 2 process 324, an I/O buffer or 
queue 325, a gateway screening (GWS) process 326, a Presence Server 
Request (PRR) stop action process 328, an SS7 MTP level 3 layer HMDC 
process 330, and an HMDT process 332. MTP level 1 and 2 processes 322 
and 324, respectively, provide the facilities necessary to send and receive 

10 digital data over a particular physical media / physical interface, as well as to 
provide error detection / correction and sequenced delivery of all SS7 
message packets. I/O queue 325 provides for temporary buffering of 
incoming and outgoing signaling message packets. GWS process 326 is 
responsible for examining the incoming signaling message and determining 

15 which, if any, of the provisioned stop actions are applicable. PRR stop 
action process 328 is responsible for making a copy of, and subsequently 
encapsulating, an incoming SS7 ISDN User Part (ISUP) IAM signaling 
message packet within an SS7 Signaling Connection Control Part (SCCP) 
formatted packet. It should be appreciated that PRR stop action process 

20 328 could also be configured to simply encapsulate the original incoming 
SS7 ISUP IAM signaling message, without making a copy. MTP level 3 
HMDC process 330 receives signaling messages from the lower processing 
layers and performs a discrimination function, effectively determining 
whether an incoming SS7 message packet requires internal processing or is 

25 simply to be through switched. For instance, in the case of an SS7 TCAP 
message associated with presence registration or an SCCP encapsulated 
ISUP IAM message, HMDC process 330 would determine that the message 
should be internally routed for further processing. HMDT process 332 
manages or directs the internal routing of SS7 message packets that require 

30 additional processing prior to final routing. Once again, it should be 
appreciated that a LIM card may contain more functional processes than 
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those described above. The above discussion is limited to LIM functionality 
associated with the basic processing of in-bound signaling messages. 

As such, it will be appreciated that the three functional processes 
associated with Advanced Data Communication Module (ADCM) 360 shown 
5 in Figure 1 1 are simply those processes that are relevant to a discussion of 
outbound ADCM operation in the examples of PS routing node operation 
disclosed herein. Furthermore, it will be appreciated that ADCM 360 is 
similar in function to the DCM application module described above. In the 
case of ADCM 360, the message packets processed by the card need not 
10 be native SS7 type messages that have been encapsulated in an IP packet. 
Instead, the ADCM 360 is capable of processing, transmitting, and receiving 
both native SS7 and native IP protocol messages. 

The processes explicitly shown on the out-bound ADCM 360 include 
an I/O queue 362 and IP level 1 and 2 processes 366 and 364, respectively. 
15 I/O queue 362 facilitates temporary buffering of incoming and outgoing 
signaling message packets, while IP addressing operations are performed 
by IP level 1 and 2 processes 366 and 364, respectively. 

Once again, the description of LIM and ADCM sub-components 
provided in the above description is limited to those sub-components that are 
20 relevant to the sample implementation scenarios discussed herein. For a 
comprehensive discussion of additional LIM and ADCM-type operations and 
functionality, the above-referenced Tekelec publications can be consulted. 

In general, a PDM card includes the database and database control 
processes necessary to facilitate the presence registration and query 
25 handling functionality of the contemplated embodiment of the present 
invention. The PDM 502 shown in Figure 11 is comprised, in part, of an 
SCCP subsystem controller known as a Signaling Connection Routing 
Controller (SCRC) process 504. a Presence Database Manager (PDMG) 
process 510, and a number of Presence Database Interface (PDI) 
30 Applications generally indicated by reference numeral 512. Included among 
the PDI Applications 512 are session initiation protocol (SIP) application 
process 518, IMPP application process 514, and presence protocol process 
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519. SCRC process 504 is responsible for discrimination of signaling 
messages and subsequent distribution of these signaling messages to an 
appropriate higher processing level application or function. In the 
configuration shown in Figure 11. the next highest processing level is 
5 represented by PDMG process 510. PDMG process 510 is generally 
responsible for determining which of the provisioned protocol-specific PDI 
Applications 512 is required process the incoming message packet. For 
instance, if the incoming presence registration packet contained a TCAP or 
SCCP-encapsulated IMPP message, PDMG process 510 would determine 
10 that the provisioned PDI application 514 was required for successful 
processing. As will be appreciated from Figure 11, a number of PDI 
applications 512 may be simultaneously provisioned on a single PDMG card. 
These protocol-specific PDI applications may be configured such that each 
application is capable of receiving presence registration or query messages 
15 that are formatted in different protocols including, but not limited to. SIP. 
IMPP. and the presence protocol. Furthermore, these PDI applications 512 
are also capable of generating or formatting protocol-specific presence 
service related response messages. Such a presence service response 
message might include, but is not limited to, a message that provides 
20 presence status information for a specific user in response to a presence 
status query. This particular scenario is specifically illustrated in Figure 11, 
where the presence status query packet assumes the form of an SS7 TCAP- 
encapsulated IMPP query message and the subsequent presence status 
response is contained within a SIP formatted message. 
25 Once again, while any number or variety of PDI applications may be 

provisioned on a single PDM card, only the IMPP, SIP, and presence 
protocol PDI applications 514, 518, and 519. respectively, are described 
herein. SIP PDI application 518 essentially contains the logic necessary to 
process incoming SIP presence messages and construct outgoing SIP 
30 presence response messages. Similarly. IMPP PDI application 514 contains 
the logic necessary to process incoming IMPP formatted presence 
messages and construct outgoing IMPP formatted presence response 
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messages. Presence PDI application 519 contains the logic necessary to 
process incoming presence query messages formatted according to the 
presence protocol and construct outgoing presence response messages 
formatted according to the presence protocol. 
5 Also included in Figure 1 1 is a general message flow associated with 

the processing of an incoming SS7 TCAP-encapsulated IMPP formatted 
presence query message and the subsequent, related presence system 
processing activity. A detailed flow chart of the major steps associated with 
a TCAP-encapsulated IMPP presence query scenario is presented in Figure 

10 12, and may be used in conjunction with the schematic diagram shown in 
Figure 1 1 to better understand the operation of presence registration and 
routing node 500. 

With particular regard to the scenario generally illustrated in Figure 
11, it is assumed that an incoming TCAP-encapsulated IMPP formatted 

15 presence query message is received at the inbound LIM module 320 (ST1). 
Once again, in steps ST2 and ST3, the incoming TCAP-encapsulated IMPP 
formatted presence query message is received and processed by the MTP 
Level 1 and 2 processes 322 and 324, respectively. With MTP Level 1 and 2 
processing complete, the signaling message packet is temporarily buffered 

20 in the I/O queue 325 before being passed up the stack to MTP Level 3 
Gateway Screening (GWS) process 326. As indicated in step ST4, GWS 
process 326 examines the incoming TCAP presence query message and 
determines not only whether the message is to be allowed into the switch for 
further processing, but also which, if any, of the provisioned stop actions are 

25 applicable to the incoming message. In the scenario shown in Figure 11, 
GWS process 326 examines the incoming TCAP-encapsulated IMPP 
presence query message and determines that the message is permitted to 
enter the switch. Furthermore, upon examination of the Originating Point 
Code (OPC), Destination Point Code (DPC) and Service Indicator Octet 

30 (SIO) fields contained in the MTP routing layer, it is determined that the 
message does not require additional processing by the PRR stop action 328. 
As such, the TCAP MSU is then routed directly to HMDC process 330 where 
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SCCP type processing is performed (ST5). in the exampi. shown in Figure 
,1 HMDC prxrcess 330 examines the message packet and de<erm,nes M 
the DPC and Subsystem Number ISSN) of ma TCAP packet is the PC and 
SSN of the interna, presence sarve, da tete ea syefem fhaf is looafad » PDM 
card 502. consequently, further processing of the TCAP MSU wdh,n Ore 
rou »ng node is asaumed to be neoeseary. and me packet k passed to the 
HMDT process 332. The HMDT prooaaa 332 examinee fh. ^ »«£ 
,SI) field of the TCAP MSU, which indicates that Ota packet ,a of an SCCP 
Z. Aa such, HMDT process 332 places the TCAP MSU on high sp^ 
NT bus 310 for transport to POM 502 and subsequent presence databaae 



to 



service. 



In atep ST6. the TCAP MSU ia retsived and examined by SCRC 
pro cees 504 that ia reaidan. on PDM 502. SCRC prooaaa 504 axaminaa «» 
message, determines that preaenoa databaae eervloa is nd,cated, and 
5 towards ma TCAP MSU fo the PDMG pro«sa 510. Aa 

ST7. me message packet ia examined to detente the protocol o M. 
prese n« related measage. In mis caae. the protocol *^ — 
meaaasa ancapaulated wHhin me TCAP pa<*e. is IMPP. Next m atep ST. 
.he JU or type o, presence e^<* associated wtfh fhe message u. 
,„ evaiuated. Su* genera, pmaenoa meaaage types or vanebea m«h. 
indude.butaranotiwedto.qua^and^iatrationtypemesaagea. 

Once agam. in M. axampte. .he IMPP-tormaded preaanca servroe 
massage ia a query masaage mat * intended to extract mformadon from a 
ee™ce databaae. Aa sud, the IMPP fonnatfed « ntea^te « 
25 Led to IMPP app.cafion 514 tor further pacing. IMPP applrcatmn 
614 examinee me message and. uain, mtomratton conternad * ma 
ZZ diraote me que* to presence database 516 (ST0). M< 
alee 510 prccssses the query and. in this example, returns ma 
H*L» «o StP appltoadon 51. for « of me out-bcnd 

30 response message (ST10). , oHoH 

Wim me necessary S,P fom-ng compteta. ma StP-tomtedad 
prasacce registration masaage ia passed to an HMRT proceaa 520. HMRT 



PCTAJS01/09195 
WO 01/72055 

-29- 

process 520 determines to which ADCM card the SIP registration message 
packet should be routed for subsequent outbound transmission (ST11). In 
this case, the HMRT process 520 determines that the desired outbound 
signaling link associated with the routing of the SIP registration message .s 
5 located on ADCM 360. Consequently, the SIP message packet is .nternally 
routed across the IMT bus 310 to LIM 360. where it is generally received by 
the I/O queue process 362 (ST12). Eventually, the modified message 
packet is passed from the I/O queue 362 on to the IP Level 2 and Level 1 
processes 364 and 366. respectively. As indicated in step ST13. the SIP- 
10 formatted presence registration message is then transmitted into an IP 
network for ultimate delivery to and use by a presence database system. 

It will be appreciated from Figure 12. that if the IMPP-formatted 
presence service message were a registration request-type message, then 
,MPP application 514 would examine the message and. using information 
15 contained within the packet, direct the registration request to presence 
database 516 (ST14). In such a scenario, a response or acknowledgment 
message may not necessarily be required. 

cvtomgii y Mounted Presence natahase System 
20 The embodiments of the present invention described in detail above 

can be easily extended to include a presence registration and routing node 
that incorporates an externally mounted presence database system or server 
platform. One embodiment of such a presence registration and routing node 
is illustrated in Figure 13. and generally indicated by the numeral 600. Once 
25 again, it will be appreciated that in the particular embodiment presently 
contemplated, presence registration messages are not formulated and 
routed from the node, but instead presence registration takes place at or 
within the node. 

With particular regard to the embodiment illustrated in F.gure 13 and 
30 in a manner similar to the embodiment described above, it will be 
appreciated that presence registration and routing node 600 induces a high 
speed interprocessor Message Transport (IMT) communications bus 310. 
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Communicatively coupled to IMT bus 310 are a number of distributed 
processing modules or cards including: a pair of Maintenance and 
Administration Subsystem Processors (MASPs) 312, an SS7 capable Link 
Interface Module (LIM) 320, an IP capable Advanced Data Communication 
5 Module (ADCM) 360, and an External Presence Database Module (EPDM) 
700. As further indicated in Figure 13. EPDM is connected to an external 
Presence Database Server platform 800 via a high-speed Ethernet-type 
connection 802. In this embodiment, external Presence Database Server 
platform 800 includes the actual Presence Database entity 516. With 
10 exception of the EPDM card 700 and external Presence Database Server 
800, all other functional and operational aspects of the embodiment shown 
in Figure 13 are identical to that of the embodiment shown in Figure 11 and 
generally described above. 

In general, an EPDM card 700 includes the database and database 
1 5 control processes necessary to facilitate the presence registration and query 
handling functionality of the contemplated embodiment of the present 
invention. The EPDM 700 shown in Figure 13 is comprised, in part, of an 
SCCP subsystem controller known as a Signaling Connection Routing 
Controller (SCRC) process 504. a Presence Database Manager (PDMG) 
20 process 510. and a number of Presence Database Interface (PDI) 
Applications generally indicated by the numeral 512. Included among the 
PDI Applications 512 are a session initiation protocol (SIP) application 
process 518, an IMPP application process 514, and a presence protocol 
process 519. The SCRC process 504 is responsible for discrimination of 
25 signaling messages and subsequent distribution of these signaling 
messages to an appropriate higher processing level application or function. 
In the configuration shown in Figure 13. the next highest processing level is 
represented by the PDMG process 510. PDMG process 510 is generally 
responsible for determining which of the provisioned protocol-specific PDI 
30 Applications 512 is required process the incoming message packet. The PDI 
applications 512 are capable of generating or formatting protocol-specific 
presence service related response messages. Such a presence service 
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response message might include, but is not limited to. a message that 
provides presence status information for a specific user in response to a 

presence status query. 

In the embodiment shown in Figure 13, EPDM card 700 further 

5 includes an Ethernet Controller (EC) process 702 which is communicatively 
coupled to the provisioned PDI applications 512 and also to the external 
Presence Database Server 800. More particularly, EC 702 is coupled to a 
corresponding EC process 802 that resides on the external Presence 
Database Server 800. ECs 702 and 802 facilitate the communication of 

10 messages between the PDI applications 512 and the Presence Database 
516. In all other respects, operation of the presence registration and routing 
node is identical to that of presence registration and routing node 500 
described above and illustrated in Figure 11. 

15 integrated Message Accoun ting And Billing Subsystem 

Shown in Figure 14 is another embodiment of a presence registration 
and routing node of the present invention, generally indicated by the numeral 
900. With particular regard to the embodiment illustrated in Figure 14 and in 
a manner similar to the embodiment described above, it will be appreciated 
20 that presence registration and routing node 900 includes a high speed 
Interprocessor Message Transport (IMT) communications bus 310. As in the 
previously described embodiments, communicatively coupled to IMT bus 
310 are a number of distributed processing modules or cards including; a 
pair of Maintenance and Administration Subsystem Processors (MASPs). an 
25 SS7 capable Link Interface Module (LIM) 320. and an IP capable Advanced 
Data Communication Module (ADCM) 360. and a Presence Registration 
Module (PRM) 340. Further included in the presence registration and 
routing node 900 is an accounting and billing subsystem which is comprised 
of an accounting subsystem interface module (ASIM). generally indicated by 
30 the numeral 910. and an accounting server platform <ASP). generally 
indicated by the numeral 920. It will be appreciated that the combination of 
ASIM card 910 and ASP accounting server 920 includes the database and 



01/72055 W - PCT/US01/09195 

-32- 

control processes necessary to achieve the accounting and billing 
functionality of the present invention. From a practical implementation 
standpoint, ASP 920 could assume the form of a Sun Workstation or similar 
type computing platform. It will be further appreciated that an entire 
message accounting subsystem could also be integrated within a presence 
routing and registration node. 

The ASIM card 910 shown in Figure 14 includes a Signaling 
Connection Control Part (SCCP) subsystem 912 that is responsible for 
receiving and preliminary processing of incoming SCCP encapsulated 
accounting message packets. ASIM card 910 also includes an SCCP 
controller known as a Signaling Connection Routing Controller (SCRC) 
process 914 and a high-speed Ethernet Controller (EC) process 916. Once 
again, as described above, the SCCP subsystem 912 is responsible for 
receiving and preliminary processing of incoming SCCP encapsulated 
message packets, while the SCRC process 914 is responsible for 
discrimination and subsequent distribution of messages based on 
information contained in an SCCP packet. In the case of ASIM card 910. 
messages that satisfy the SCRC discrimination criteria are distributed or 
directed to the high-speed Ethernet Controller process 916. EC process 916 
is in turn responsible for controlling the process of communicating 
messages, via an Ethernet connection to and from the associated ASP 
server 920. More particularly, ASP server 920 includes a corresponding 
high-speed Ethernet Controller process 922 that serves as the 
communications interface between ASIM card 910 and an on-board 

i accounting server manager (ASM) process 924. ASM process 924 is 
responsible for the de-capsulation or removal of the SCCP envelope that 
contains the accounting message. The de-capsulated accounting message 
is then passed to an adjacent usage and measurements process 926 where 
usage and measurement statistics are created and stored in a usage and 

) measurements database (UMD) process 930, such as that shown in Figure 
15. 
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Usage and measurements statistics produced by such a process 
could include, but are not limited to, peg counts of messages received from a 
specific network address, a specific service provider, a specific service user, 
a specific IP socket, or a specific signaling link. Furthermore, information 

5 specific to the type of service requested, calling and called party information, 
and other information associated with a communication that could be useful 
in generating a bill or invoice may also be stored in a UMD. As shown in 
sample UMD process 930. in one simplified embodiment, each 
communication is identified by a transaction ID, and certain predetermined 

10 information associated with a communication can be stored in the database. 
It will be appreciated that the information contained in a UMD database 
could be significantly more or less detailed than that indicated in the example 

shown in Figure 15. 

in any event, such statistics could include information associated w.th 
15 the time-of-day that a message was received, the duration of a "call" or 
communication, general quality of service (QoS) indicators associated with a 
-call" or communication, information related to or identifying the type of 
service that is associated with a 'call" or communication (i.e., broadband 
service related, call setup related, database query related, etc.). Such usage 
20 information could be used to bill a subscriber at dtfferent rates depending 
upon the type of service requested. With such capability included wrth.n a 
presence server and routing node, network operators greatly increased 
flexibility with regard to serospecific billing, without significantly 
increasing network OA&M requirements. 
25 In order to facilitate such billing operations, ASP server 920 also 

includes a billing process 928 that is adapted to extract information stored by 
the usage and measurements process 926 and subsequently generate b.lls. 
Once again, information or parameters maintained by process 926 that may 
be used in the generation of bills could include, but is not limited to, a 
30 network address identifier, a service provider identifier, a service user 
identifier, an IP socket identifier, a signaling link identifier, and a service type 
identifier. It will be further appreciated that a network address identifier could 



WO 01/72055 




PCT/US01/09195 



-34- 

include, but is not limited to a destination or origination SS7 point code, a 
destination or origination IP address, and a destination or origination domain 
name. Similarly, a user identifier could include, but is not limited to a calling 
or called party telephone number, and a destination or origination email 
5 address. 

In the particular embodiment shown, LIM card 320 includes a 
Presence Registration Request (PRR) stop action process 902, that is 
functionally similar to the PRR process 328 described above. In addition to 
generate, and SCCP encapsulate an accounting message that is 

10 subsequently passed via IMT bus 310 to ASIM 910 of the accounting and 
billing subsystem. 

In a preferred embodiment, a normalized accounting message (NAM) 
format is employed to provide the necessary message information content to 
the associated accounting and billing subsystem. That is, a NAM formatted 

15 accounting message employs a field or record structure that is essentially a 
superset of all parameters of interest from all signaling, presence and instant 
messaging protocols of interest. As such, parameters of interest in a SIP 
formatted signaling message can be easily accommodated in a NAM 
accounting message, as can parameters of interest in an SS7 formatted 

20 signaling message. It will be further appreciated that the NAM format can be 
periodically expanded (or revised) to accommodate new or evolving 
signaling protocols that must be supported by a presence registration and 
routing node of the present invention. LIM card 320 can also be configured 
to simply encapsulate a copy of the received signaling message packet and 

25 forward the packet to the associated accounting and billing subsystem. 

With regard to the message encapsulation discussed above, it should 
be appreciated that SCCP encapsulation of a NAM message is not essential 
to the operation of the message accounting subsystem of the present 
invention. Other internal encapsulating protocols could be just as easily 

30 employed, provided that a suitably provisioned ASIM module is capable of 
receiving and processing the encapsulated messages. In fact, no 
encapsulation necessarily need be performed, so long as the accounting 
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message generated by a PRR type process can be received and generally 
processed by a suitable configured ASIM module. 

Figure 16 illustrates yet another embodiment of a presence 
registration and routing node of the present invention, which extends the 
5 integrated accounting and billing subsystem concept to the routing node 
previously presented in Figure 11. This new embodiment of a presence 
server and routing node is generally indicated by the numeral 950. With 
particular regard to the embodiment illustrated in Figure 16 and in a manner 
similar to those embodiments described above, it will be appreciated that 

10 presence registration and routing node 950 includes a high speed 
Interprocessor Message Transport (IMT) communications bus 310. 
Communicatively coupled to IMT bus 310 are a number of distributed 
processing modules or cards including: a pair of Maintenance and 
Administration Subsystem Processors (MASPs), an SS7 capable Link 

15 Interface Module (LIM) 320, and an IP capable Advanced Data 
Communications Module (ADCM) 360, and a Presence Registration Module 
(PRM) 340. Further included in the presence registration and routing node 
950 is an accounting and billing subsystem which is comprised of an 
accounting subsystem interface module (ASIM), generally indicated by the 

20 numeral 910, and an accounting server platform (ASP), generally indicated 
by the numeral 920. Again, it will be appreciated that the combination of 
ASIM card 910 and ASP accounting server 920 includes the database and 
control processes necessary to achieve the accounting and billing 
functionality of the present invention. 

25 In the particular embodiment shown, LIM card 320 includes a 

Presence Registration Request (PRR) stop action process 952, that is 
functionally similar to the PRR process 902 described above. PRR 952 is 
adapted to generate, and SCCP encapsulate, an accounting message that is 
subsequently passed via IMT bus 310 to ASIM 910 of the accounting and 

30 billing subsystem, where accounting and billing subsystem processing 
occurs in a manner similar to that described above. 
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It will be understood that various details of the invention may be 
changed without departing from the scope of the invention. Furthermore, the 
foregoing description is for the purpose of illustration only, and not for the 
purpose of limitation— the invention being defined by the claims. 
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CLAIMS 

What is claimed is: 

A method for updating presence information regarding an end user in 
a presence server database based on information derived from a 
telephony-related action, the method comprising: 

(a) receiving a signaling system seven (SS7) message in 
response to a telephony-related action performed by an end 
user; 

(b) in response to receiving the SS7 message, formulating an 
internet protocol (IP) message for updating presence 
information regarding the end user managed by a presence 
server; and 

(c) transmitting the IP message to the presence server over an IP 
network. 

2 The method of claim 1 wherein the telephony-related action includes 
dialing a called party telephone number utilizing a PSTN telephone 
and the signaling system seven message is an IAM message. 
3. The method of claim 1 wherein the telephony-related action includes 
entering DTMF digits using a PSTN telephone handset after a call has 
been established, the DTMF digits forming a code for instructing an 
end office to formulate the SS7 message. 

4 The method of claim 3 wherein the SS7 message is a transaction 
capabilities application part (TCAP) message containing presence 
information for the end user. 

5 The method of claim 1 wherein the telephony-related action is the 
activation of a mobile telephone handset and the SS7 message is a 
message for updating the status of the subscriber in at least one of a 
home location register (HLR) and a visitor location register (VLR). 

6 . The method of claim 1 wherein formulating an IP message includes 
30 formulating a presence protocol message. 

7. The method of claim 1 wherein formulating an IP message includes 
formulating a session initiation protocol (SIP) message. 
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8. 



9. 



10. 



The method of claim 1 wherein formulating an IP message includes 
formulating an instant messaging and presence protocol (IMPP) 
message. 

The method of claim 1 comprising, in response to receiving the SS7 
message, sending a second message to an accounting and bill.ng 
system. 

The method of claim 9 wherein the second message is a copy of the 
SS7 message. 

11. A method for processing a query to a presence server database, the 

10 method comprising: 

(a) receiving, at presence registration and routing node, an IP 
message for determining presence information for an ent.ty; 

(b) formulating a query to a presence database for obtaining the 
presence information; 

15 (c) obtaining the presence information from the presence 

database; and 

(d) forwarding the presence information to an end user. 
The method of claim 11 wherein receiving an IP message includes 
receiving a presence protocol message. 

The method of claim 12 wherein receiving a presence protocol 
message includes receiving a fetch message requesting presence 
information regarding the entity. 

14 The method of claim 11 wherein forwarding the presence informat.on 
to an end user includes forwarding a presence protocol message to 

25 the end user. 

15 The method of claim 14 wherein forwarding a presence protocol 
message includes forwarding a notify message to the end user. 

16. The method of claim 1 1 wherein receiving an IP message includes 
receiving a session initiation protocol (SIP) message. 
30 17 The method of claim 1 1 wherein receiving an IP message includes 
receiving an instant messaging and presence protocol (IMPP) 
message. 
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18. The method of claim 11 wherein obtaining the presence information 
from the presence database includes obtaining the presence 
information from a presence database located internal to the 
presence registration and routing node. 

5 19 The method of claim 11 wherein obtaining the presence information 
from the presence database includes obtaining the presence 
information from a presence database located external to the 
presence registration and routing node. 
20 The method of claim 11 comprising, in response to receiving the IP 

10 message, sending a second message to an accounting and billing 

system. 

21 . The method of claim 20 wherein the second message is a copy of the 
IP message. 

22. A presence registration and routing node for updating presence 
15 information regarding an end user in a presence server database, the 

presence registration and routing node comprising: 

(a) a communication module for receiving an SS7 message from 
an SS7 network; and 

(b) a presence server message generator for generating a 
20 presence-server-compatible message for updating presence 

information regarding an end user in a presence server 
database, based on the SS7 message. 
23 The presence registration and routing node of daim 22 comprising an 
advanced data communication module for encapsulating the 
25 presence-server-compatible message in an IP packet and transmitting 

the IP packet to a presence server over an IP network. 
24. The presence registration and routing node of claim 22 wherein the 
presence-server-compatible message is a session initiation protocol 
(SIP) message. 

30 25. The presence registration and routing node of claim 22 wherein the 
presence-server-compatible message is a presence protocol 
message. 
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26. The presence registration and routing node of claim 22 wherein the 
presence-server-compatible message is an instant messaging and 
presence protocol (IMPP) message. 

27. The presence registration and routing node of claim 22 wherein the 
5 SS7 message is an ISDN user part (ISUP) message. 

28. The presence registration and routing node of claim 22 wherein the 
SS7 message is a transaction capabilities application part (TCAP) 
message. 

29. The presence registration and routing node of claim 22 wherein the 
1 0 SS7 message is a message from a mobile switching center (MSC). 

30. The presence registration and routing node of claim 22 comprising a 
presence server database operatively associated with the presence 
server message generator for receiving the presence-server- 
compatible message and for extracting the presence information in 

1 5 response to the presence-server compatible message. 

31. The presence registration and routing node of claim 30 wherein the 
presence server database is located internal to the presence 
registration and routing node. 

32. The presence registration and routing node of claim 30 wherein the 
20 presence server database is located external to the presence 

registration and routing node. 

33. The presence registration and routing node of claim 22 wherein the 
presence server message generator is adapted to receive presence 
queries, forward the presence queries to a presence server database, 

25 and receive responses from the presence server database. 

34. The presence registration and routing node of claim 22 comprising: 
(a) means for generating an accounting message based on at 

least one of the SS7 message received by the communication 
module and the presence-server-compatible message; and 
30 (b) an accounting and billing system for storing accounting 

information based on the accounting message. 
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35. A presence registration and routing node for providing presence 
information regarding an entity, the presence registration and routing 
node comprising: 

(a) an advanced data communication module for receiving an IP- 
5 encapsulated presence-server-compatible message for 

determining presence information for an entity; and 

(b) a presence server message processor for forwarding the 
presence-server-compatible message to a presence server for 
determining the presence information. 

10 36. The presence registration and routing node of claim 35 wherein the 
presence server message processor is adapted to receive the 
presence information from the presence server and forward the 
presence information to the advanced database communications 
module. 

15 37. The presence registration and routing node of claim 36 wherein the 
advanced database communications module is adapted to forward 
the presence information to an endpoint over an IP network. 

38. The presence registration and routing node of claim 35 comprising a 
presence server operatively associated with the presence server 

20 message processor for providing the presence information to the 

presence server message processor. 

39. The presence registration and routing node of claim 38 wherein the 
presence server is located internal to the presence registration and 
routing node. 

25 40. The presence registration and routing node of claim 38 wherein the 
presence server is located external to the presence registration and 
routing node. 

41 . The presence registration and routing node of claim 35 comprising: 

(a) means for generating an accounting message based on the 
30 presence-server-compatible message; and 

(b) an accounting and billing system for storing accounting 
information based on the accounting message. 
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A computer program product comprising computer-executable 
instructions embodied in a computer-readable medium for performing 
steps comprising: 

(a) receiving a signaling system seven (SS7) message in 
5 response to a telephony-related action performed by an end 

user 

(b) in response to receiving the SS7 message, formulating an 
internet protocol (IP) message for updating presence 
information regarding the end user managed by a presence 

10 server; and 

(c) transmitting the IP message to the presence server over an IP 

network. 

43 The computer program product of claim 42 wherein the telephony- 
related action includes dialing a called party telephone number 
utilizing a PSTN telephone and the signaling system seven message 

is an IAM message. 

44 The computer program product of claim 42 wherein the telephony- 
related action includes entering DTMF digits using a PSTN telephone 
handset after a call has been established, the DTMF digits forming a 
code for instructing an end office to formulate the SS7 message. 

45 The computer program product of claim 42 wherein the SS7 message 
is a transaction capabilities application part (TCAP) message 
containing presence information for the end user. 

46 The computer program product of claim 42 wherein the telephony- 
related action is the activation of a mobile telephone handset and the 
SS7 message is a message for updating the status of the subscriber 
in at least one of a home location register (HLR) and a visitor location 
register (VLR). 

47. The computer program product of claim 42 wherein formulating an IP 
30 message includes formulating a presence protocol message. 
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48. The computer program product of claim 42 wherein formulating an IP 
message includes formulating a session initiation protocol (SIP) 
message. 

49. The computer program product of claim 42 wherein formulating an IP 
5 message includes formulating an instant messaging and presence 

protocol (IMPP) message. 

50. The computer program product of claim 42 comprising generating an 
accounting message in response to at least one of the SS7 message 
and the IP message and forwarding the accounting message to an 

. 1 0 accounting and billing subsystem. 

51. A computer program product comprising computer executable 
instructions embodied in a computer-readable medium for performing 
steps comprising: 

(a) receiving/at a presence registration and routing node, an IP 
1 5 message for determining presence information for an entity; 

(b) formulating a query to a presence database for obtaining the 
presence information; 

(c) obtaining the presence information from the presence 
database based on the query; and 

20 (d) forwarding the presence information to an end user. 

52. The computer program product of claim 51 wherein receiving an IP 
message includes receiving a presence protocol message. 

53. The computer program product of claim 52 wherein receiving a 
presence protocol message includes receiving a fetch message 

25 requesting presence information regarding the entity. 

54. The computer program product of claim 51 wherein forwarding the 
presence information to an end user includes forwarding a presence 
protocol message to the end user. 

55. The computer program product of claim 54 wherein forwarding a 
30 presence protocol message includes forwarding a notify message to 

the end user. 
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56 The computer program product of claim 51 wherein receiving an IP 
message includes receiving a session initiation protocol (SIP) 
message. 

57 The computer program product of claim 51 wherein receiving an IP 
5 message includes receiving an instant messaging and presence 

protocol (IMPP) message. 

58 The computer program product of claim 51 wherein obtaining the 
presence information from the presence database includes obtaimng 
the presence information from a presence database, located internal 

10 to the presence registration and routing node. 

59 The computer program product of claim 51 wherein obtaining the 
presence information from the presence database indudes obtaining 
the presence information from a presence database located external 
to the presence registration and routing node. 

15 60 The computer program product of claim 51 comprising generating an 
accounting message in response to at least one of the IP message 
and the query and forwarding the accounting message to an 
accounting and billing subsystem. 
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